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This paper presents the work of the Navigation Working Group of the Consultative 
Committee for Space Data Systems (CCSDS) on development of standards addressing the 
transfer of orbit, attitude and tracking data for space objects. Much progress has been 
made since the initial presentation of the standards in 2004, including the progression of the 
orbit data standard to an accepted standard, and the near completion of the attitude and 
tracking data standards. The orbit, attitude and tracking standards attempt to address 
predominant parameterizations for their respective data, and create a message format that 
enables communication of the data across space agencies and other entities. The messages 
detailed in each standard are built upon a keyword = value paradigm, where a fixed list of 
keywords is provided in the standard where users specify information about their data, and 
also use keywords to encapsulate their data. The paper presents a primer on the CCSDS 
standardization process to put in context the state of the message standards, and the 
parameterizations supported in each standard, then shows examples of these standards for 
orbit, attitude and tracking data. Finalization of the standards is expected by the end of 
calendar year 2007. 


Introduction 

The development of standards, most particularly in space mission operations, has been an ongoing area of 
international cooperation between space agencies in recent years. The Consultative Committee for Space Data 
Systems (CCSDS) represents the technical branch of the International Standards Organization (ISO) Technical 
Committee 20, Subcommittee 13, and works to develop standards targeting spacecraft mission operations, intra- 
spacecraft, and spacecraft to ground communications, to name a few. A group within the organization of CCSDS is 
the Mission Operations and Information Management Services Area (MOIMS), which addresses standards in 
mission operations, information exchange formats, and spacecraft monitoring and control standards, among others. 
For further infomiation on the mission of the CCSDS and the technical organization, please see the web pages at 
http://www.ccsds.org. 

The MOIMS area is broken into what are known as Working Groups (WG), and one of those working groups is the 
Navigation Working Group. This group has worked to address the standardization of spacecraft navigation data by 
developing three standards: an orbit message, attitude message, and a tracking data message. Each standard has 
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been developed to communicate the necessary data elements in a compact format that is readable to the human eye 
and also readable by computers, which enables the input of navigation data to be automated in a mission operations 
situation. The navigation standards take advantage of international standards currently in place as well, such as the 
specification of a standard alphabet (ISO/IEC 8859-1: 1998) [6], and a standard representation of numerical values 
based on IEEE Standard 754-1985 [7]. 

The three standards, Orbit Data Message (ODM) [1], Attitude Data Message (ADM) [2], and the Tracking Data 
Message (TDM) [3], will be detailed in the following sections. The approach to the development of each standard 
will be presented, along with relevant keywords and examples on using the standard. Also discussed will be the 
operationally relevant environment for such a standard. Status updates will discuss the substantial work that has 
been accomplished since 2004 when these standards were first discussed at the International Symposium on Space 
Flight Dynamics (ISSFD) [9]. What will not be discussed, but are still a large part of the use of these standards, are 
the Navigation Green Book [4] and the XML Specification [5]. The Navigation Green Book gives a primer on the 
use of the data contained in these messages, to demonstrate how to interpret the data, and to show how one would 
use the data to derive other relevant information. Work on this document continues and a final version will be 
published in 2008. The XML Specification is a standard that will detail how to format the ODM, ADM, and TDM 
(collectively called the Navigation Data Messages (NDM)) using the XML parsing language, and will be finalized in 
2008 as well. 


Primer on the CCSDS Standardization Process 

The CCSDS Standardization Process is defined in detail in [10]. In brief, standards proceed through the following 
levels: 

• CCSDS Concept Paper: discusses the concept of standardization in a designated area. In order to progress, the 
CCSDS Engineering Steering Group (CESG) must endorse the concept and assign it to a Working Group. 

• CCSDS Proposed Standard (“White Book”): expands on the Concept Paper. The White Book is developed by 
the chartered Working Group. In order to progress, the document must be reasonably mature and ready for 
formal review outside the Working Group. 

• CCSDS Draft Standard (“Red Book”): a formal release by the CCSDS Secretariat. The Red Book is made 
available on its web site for what is termed the “Agency Review”. In order to progress, the Working Group is 
obligated to consider and formally respond to comments submitted by reviewers, a process which usually 
requires some degree of change in the document. Depending on the magnitude of the changes, one or more 
additional Agency Reviews may be required. Another condition for progressing is that “at least two 
independent and interoperable prototypes or implementations must have been developed and demonstrated in an 
operationally relevant environment, either real or simulated” [10]. Such prototyping establishes the viability of 
the concept. 

• CCSDS Recommended Standard (“Blue Book”): Once the CESG is satisfied that the Agency Review and 
prototyping requirements have been met, the document becomes a Recommended Standard. A Blue Book is 
subject to review and potential revision after 5 years, or sooner if conditions warrant. The CCSDS 
Recommended Standards are suitable for infusion into space operations, which can be one of the most complex 
yet rewarding aspects of the standardization process. CCSDS Blue Books also enter the ISO voting process at 
an advanced level (Final Draft International Standard). 

At each level of the process, the document becomes more mature and more formal. There are some subtleties and 
technicalities to the process, but the above fairly well represents the fundamentals. CCSDS documents that have 
gone all the way through the CCSDS Standardization Process are available without charge at 
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http://public.ccsds.org/publications/default.aspx. Furthermore, the CCSDS Working Groups are encouraged to work 
in the open and all working standards are in the public domain. Thus it is possible for interested parties to observe 
the progress of CCSDS Navigation Working Group White Book and Red Book drafts for [1], [2], [3], and [5], and 
the draft for the Green Book [4], at http://cwe.ccsds.org/moims/docs/MOIMS-NAV/Draft%20Documents/. 

Common Navigation Information 

The structure of the Navigation Data Messages relies on a key design feature - the keyword = value paradigm. In 
order for the standard to then be useful in an operational environment, the set of keywords must be fixed. The 
keywords are used to navigate through a message and for the end user to ferret out the bits of information for their 
application. There are keywords in the NDM messages that are allowed particular values, while others are used to 
denote the data being transferred. Many of the keywords with particular values enable the user to interpret the data 
in the message correctly and unambiguously. 

While the NDMs each address significantly different information at their core, there is much in common with the 
suite of messages. Each message’s information relies on the specification of time and coordinate frames. These 
particular elements of the messages will be discussed in this section. In addition to these common technical 
elements, there is much in common in terms of ancillary information regarding the specification of the genesis of a 
particular message. Information such as a message version number, a field for the agency creating the message, a 
date the message was created, vehicle naming, and comments have all been standardized across the Navigation Data 
Messages. 

All NDMs contain a section in the message known as the header. Contained in this section are items such as 
message version number, the date and time the message was created, and the agency originating the message. 
Following the header is the metadata section, whose contents vary between the NDMs, but each contains keywords 
for the time system, and the reference frame(s) being employed in the message. Considering the number of different 
time systems in existence, NDMs rely on [11] to standardize the format of the date and time. The standard does not 
attempt to explain the myriad time systems, but rather provide a means to specify the time system used in a message. 
It is up to the user to understand the time system in a given message. The Navigation WG has included several 
allowed values for time systems, which include many of the current time systems in use (UTC, TAI, GPS, TDB, TT, 
etc.). The standard also allows for the use of any future time system as long as the agencies exchanging messages 
specify the different key word values in an Interface Control Document (ICD). 

Turning to the specification of coordinate frames, these have been addressed by introducing various key words in 
each of the three messages that are used to communicate reference frame information. For instance, in the Orbit 
Data Message, the key word REF_FRAME is used. However, for the Attitude Data Message, the specification of 
attitude requires two reference frames to specify the rotation, typically an inertial reference frame and a body-fixed 
reference frame. The keyword for one of the reference frames in the rotation is provided by the keyword 
*_FRAME_A, where * is replaced by a prefix pertinent to the type of data. Similarly, the other half of the reference 
frame specification is provided by *_FRAME_B. The values for many inertial reference frames and some local 
orbital reference frames have been standardized in the NDM messages. However, the exchange of NDMs can be 
enhanced with additional features and other keyword values through an ICD. The NDMs currently support many of 
the Earth-centered and orbital reference frames (EME2000, ITRF, LVLH, RTN, etc.), and also the International 
Celestial Reference Frame (ICRF). 

The definition for each of the values of these keywords is or will be covered in the Navigation Green Book, [4]. The 
Green Book is not an approved standard, but rather a technical handbook that will provide fundamental concepts of 
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the navigation process, address the definitions of certain keyword values and demonstrate the use of the information 
contained in the NDMs. However, since it is not an approved standards document, it is not required to adhere to the 
same strict rules of review as a standard, and as such the information contained in it is caveat emptor. 

The NDM messages also address format and detail a standard approach to formatting in each message. NDMs use 
ASCII [6], a common format used in all computing architectures, as the basis for the message format. Thus there is 
a reasonably high probability that any given agency can process an ASCII-based NDM. There is also no 
requirement on any agency to use software provided by another agency. While some tracking data users may wish 
to contract with each other to provide software, it is not a requirement of the standard. Finally, insofar as possible, 
all of the NDMs use units that are part of the International System of Units (SI Units); units are either SI base units, 
SI derived units, or units outside the SI that are accepted for use with the SI. There are a small number of specific 
cases where units that are more widely used in the navigation community are specified, but every effort has been 
made to minimize these departures from the SI [12]. 


Orbit Data Message 

The specification of the orbit of an object is normally achieved, in high fidelity applications, by specifying the 
position and velocity of the object in a given reference frame at a given epoch. Many other parameterizations of the 
orbit exist that use quantities giving more insight into the motion of the object, such as mean elements, orbital 
elements, etc. However, the specification of the position and velocity is unambiguous, and as such, the ODM 
adopted the specification of the position and velocity of an object as the obligatory parameterization of an orbit, and 
all other values are optional. 

The ODM is divided into two separate messages, the Orbit Parameter Message (OPM) and the Orbit Ephemeris 
Message (OEM). The OPM is intended to specify the orbit of the object at a single instant in time, and allows for 
the specification of Cartesian coordinates and Keplerian elements in the message, as well as orbit maneuver 
information, solar radiation information and aerodynamic drag information. The OEM is intended to specify the 
orbital state at multiple epochs in a single message. These two messages constitute the standard for specifying 
orbital state information. The ODM also details not only the keywords allowed in the message, but information on 
the allowable format of the data lines and syntax allowed for text keywords and comments. 

Orbit Parameter Message (OPM) 

The OPM specifies keywords, in addition to the time and reference frame keywords, to specify the orbital state of an 
object at a single designated epoch. Generation of the orbital state is not the intent of the standard, or of this paper, 
but only the clear, concise and compact specification of the orbital state. The message is divided into a header, a 
metadata, and finally a data section to specify not only the orbital state, but also parameters that enable the 
appropriate interpretation of the orbital state by the end user. The information contained in the metadata section is 
summarized in Table 1. 


Table 1: Metadata Section of an OPM 


Keyword 

Description 

Example Values 

OBJECTNAME 

OBJECTID 

Keywords provided to describe the object 

MYSAT 
20 15 -004b 

CENTER_NAME 

Keyword to specify the center of the reference frame 

earth 

MARS 

REFFRAME 

Keyword to specify the reference frame that the orbital 

J2000 
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state is given 

EME2000 

TIMESYSTEM 

The time system used to interpret epoch information 

UTC 

TAI 


After the metadata section, there are keywords specified that allow for the specification of the orbital state. In the 
case of position and velocity, the keywords provided are X, Y, Z, X DOT, Y DOT, Z DOT. These keywords are 
mandatory in every OPM. The units associated with the position and velocity information are kilometers (km) and 
kilometers per second (km/s), respectively. There are also keywords provided to specify Keplerian elements, and 
those are SEMIMAJORAXIS, ECCENTRICITY, INCLINATION, RAOFASCNODE, 
ARG OF PERICENTER, TRUE_ANOMALY, MEAN_ANOMALY, and GM, which are all self-explanatory. 
Note that only either true anomaly or mean anomaly needs to be specified for a complete parameterization of the 
orbital state. The specification of the Keplerian elements is optional. 

Additional keywords are provided to enable the user to propagate the provided orbital state to a time different than 
the given epoch. A quantity necessary for this purpose is the mass of the object, specified using the keyword 
MASS. To determine the effect of solar radiation pressure, the user would need the area normal to the Sun vector 
(SOLAR RAD AREA), and the solar radiation coefficient (SOLAR RAD COEFF). Similarly, to predict the 
aerodynamic drag effect on the orbital state, the user would need the area normal to the velocity vector 
(DRAGAREA) and the drag coefficient (DRAGCOEFF). The specification of these keywords is obligatory and 
must be provided in every OPM. Normally orbital states are produced from a curve fit to tracking data 
measurements, and these parameters are necessary to properly propagate the orbital state determined in this manner. 


In addition to the orbital state parameterization, keywords are provided in the OPM to specify orbital maneuvers. 
The maneuver is parameterized using the epoch of the maneuver, the duration of the maneuver, the mass expelled 
during the maneuver, the reference frame applicable to the maneuver, and finally the delta velocity being applied in 
the given reference frame. The keywords provided for this purpose are MAN_EPOCH_IGNITION, 
MAN DURATION, MAN DELTA MASS, MAN REF FRAME, MAN_DV_1, MAN_DV_2, MAN_DV_3, 
respectively. Unlike the object parameters, maneuver parameters are optional. An example OPM is provided in 
Figure 1, which specifies the maneuver duration as zero seconds, implying an impulsive maneuver. 


Figure 1: Example OPM specifying a Maneuver 


CCSDS_OPM_VERS 

CREATION_DATE 

ORIGINATOR 

OBJECT_NAME 

OBJECT_ID 

CENTER_NAME 

REF_FRAME 

TIME SYSTEM 


= 1.0 

= 2013-08-29T14:56:34 
= JAXA 
= THISSAT 
= 2012-003b 
= EARTH 
= ITRF-97 
= UTC 


EPOCH 

X 

Y 

Z 

X_DOT 

Y_DOT 

Z_DOT 

MASS 

SOLAR_RAD_AREA 
SOLAR_RAD_COEFF 
DRAG AREA 


= 2013-08-29T13:35:45.688 
= 6503.514000 
= 1239.647000 
= -717.490000 
= -0.873160 
= 8.740420 

= -4.191076 
= 3000.0000 
= 18.770000 
= 1.000000 
= 18.770000 
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DRAG COEFF 


2.50000 


COMMENT Impulsive maneuver, duration set to 0 seconds 


MAN_E POCH_I GN I T I ON 

MAN_DURAT I ON 

MAN_DELTA_MASS 

MAN_REF_FRAME 

MAN_ DV _ 1 

MAN_ DV _2 

MAN DV 3 


= 2013-08-29T13:41:32.544 
= 0.00 

= -1.469 [KG] 

= RTN 

= 0.001015 
= -0.001873 
= 0.000000 


Orbit Ephemeris Message (OEM) 

An OEM is intended to specify the orbital history of an object and allow for high fidelity interpolation between 
epochs specified in the OEM. The OEM is also divided into a header, metadata and data sections, similar to the 
OPM. The OEM is quite different in that it provides a sequence of data in a compact form. As such, more 
information is relayed in the metadata. In addition to the keywords provided in the OPM, the OEM allows for the 
specification of a start and stop time (START_TIME, STOP_TIME), and the specification of a sub-block of the data 
that is useful using the keywords USEABLESTARTTIME and USEABLESTOPTIME. Finally, the message 
allows for the specification of an interpolation method to be used on the data with the keyword 
INTERPOLATION METHOD and INTERPOLATIONDEGREE. These keywords, along with the keywords 
provided in Table 1 for the OPM, constitute the metadata section for an OEM. The data section of the message has 
a single format to specify the orbital state at various epochs. The data lines are formatted in the order of the epoch, 
the x, y and z components of position and the x, y, and z components of velocity of the object. The limits on the 
formatting of the data lines and the syntax of the OEM message are provided in [1], An example OEM is provided 
in Figure 2. 


CCSDS_OEM_VERS =1.0 

CREATION_DATE 

ORIGINATOR 

META_START 

OBJECT_NAME 

OBJECT_ID 

CENTER_NAME 

REF_FRAME 

TIME_SYSTEM 

STARTJIIME 

STOP_TIME 

META STOP 


Figure 2: Example OEM 


= 2015-09-20T18 : 32 : 45 
= NASA/ JPL 

= MARS MYSAT 
= 2014-04 5b 
= MARS BARYCENTER 
= EME2000 
= UTC 

= 2015-09-20T13:34:32.544 
= 2015-09-20T13:58:45.944 


2015-09-20T13:34:32.544 2789.619 -280.045 -1746.755 4.73372 -2.49586 -1.04195 


2015-09-20T13:58:45.944 -3881.024 563.959 -682.773 -3.28827 -3.66735 1.63861 


Note that the ODM has been assimilated into the operations environments of several of the CCSDS Member 
Agencies. The OEM is the format used by European Space Agency (ESA) for submission of spacecraft 
ephemerides to NASA’s Jet Propulsion Lab (NASA/JPL) for tracking of multiple ESA spacecraft (Mars Express, 
Venus Express, ROSETTA) by the Deep Space Network (DSN). The OEM has also been used to deliver trajectories 
to ESOC for possible contingency tracking (e.g. Mars missions, SOHO). Additionally, The Japan Aerospace 
Exploration Agency may use the OEM for DSN tracking of the SELENE spacecraft. The OPM has been 
implemented at the DSN, NASA/JPL Navigation, Deutsches Zentrum fur Luft-und Raumfahrt (DLR), Centre 
National d’Etudes Spatiales (CNES), and European Space Operations Centre (ESOC), and is used frequently for 
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external support. Finally, while this paper does not discuss the XML specification of the Navigation Data Messages, 
it is worth noting that the forthcoming CCSDS Service Management Recommended Standard directly incorporates 
the XML representations of the OEM and OPM messages [5], 

Currently the ODM is being extended via collaboration of the CCSDS (ISO TC20/SC13) with the other space-based 
ISO subcommittee (ISO TC20/SC14). These two subcommittees of the ISO Technical Committee 20 both cover 
space-related standardization, but serve different user communities. The ODM is the current international standard 
for the representation of an orbit (ISO 22644), and it is being extended to accommodate requirements raised by the 
TC20/SC14. In particular, these extensions include the addition of information regarding the uncertainty of orbit 
states (covariance matrix); addition of accelerations to the OEM state; more extensive documentation of the inputs 
to the development of the navigation solution; and a new message type that is based upon the NORAD Two Line 
Elements (TLE), which over the years has become the “de facto” standard for the representation of mean orbital 
elements. 


Attitude Data Message 

The definition of attitude is the orientation of one coordinate frame with respect to another. As it relates to a space 
object, Wertz [8] defines the attitude as “the orientation in space”. The parameterization of the attitude can take 
many forms, but the information conveyed must at a minimum address the following to give an unambiguous 
attitude: 

epoch of the attitude 

coordinate system being transformed from (1) 
coordinate system being transformed to (2) 
attitude parameters 

In addition to these parameters, to propagate the attitude one would need the rotational rates of coordinate system 1 
with respect to coordinate system 2, which can be expressed in either coordinate system. Depending on the 
particular parameterization of the attitude, additional information may be necessary to fully specify an unambiguous 
attitude. It is the goal of this standard to delineate a format and keywords that allow the exchange of attitude 
information in an unambiguous manner. This section will give a brief overview of the attitude parameterizations 
addressed with this standard, a handful of the keywords used to specify the attitude, give an example use of the 
standard, and conclude with the road ahead for the standard. 

The ADM standard is divided into two messages, an Attitude Parameter Message (APM), and an Attitude 
Ephemeris Message (AEM). The APM is intended for specifying an attitude at a given instant in time, and if 
appropriate, specifying the attitude rates of the object at the same time for use in propagating the attitude. The AEM 
is intended to specify a list of attitude transformations at various times. Much is similar between the two messages 
because they both specify an attitude transformation, but the format of the message varies. 

Attitude Parameter Message (APM) 

The most widely used parameterizations of attitude are quaternions, Euler angles, and in the case of spinning 
spacecraft, spin parameters. Each parameterization requires specifying differing quantities, thus requiring a 
different set of keywords. Quaternions have gained wide use due to their lack of singularities in the evolution of the 
parameters, however Euler angles are a more intuitive quantity for engineering and analysis purposes. Due to the 
non-singular nature of quaternions, they were a natural choice as the obligatory specification of attitude in all APMs. 
All other parameterizations and keywords are optional. It is not the goal of this paper or the standard to discuss the 
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merits of either representation, but rather to discuss how each parameterization is represented. For instruction on 
using an ADM for a particular purpose, the reader is directed to [2] and [4]. 


Quaternions are a compact representation of attitude requiring four numeric values to represent the attitude, the first 
three giving the orientation of the rotation vector, and the fourth giving the magnitude of the rotation. In addition to 
specifying the attitude, it may be necessary to specify the rate of attitude change, and this can be done by specifying 
values for the derivative of the quaternion. The keywords provided for specifying the attitude using quaternions are 
Ql, Q2, Q3 for the vector portion, and QC for the scalar value. The corresponding keywords for the derivative 
terms are Q1DOT, Q2 DOT, Q3 DOT and QC DOT. In addition to these keywords, the reference frame 
keywords provided are Q_FRAME_A, which could be used to specify the inertial frame (e.g. ITRF-2000, J2000), 
and QFRAMEB, which could specify the body-fixed frame. QFRAMEA and QFRAMEB have several 
allowed values by the standard that specify a reference frame, but require an ICD for the full understanding of the 
location of the reference frame. For instance, SC_BODY, DSS_x, TAM_x, where x is an integer from 0 to 9, are all 
allowed reference frame keyword values, but require an ICD to fully specify where on the spacecraft body this 
frame is located. The usefulness of this approach is that user systems can still process any APM message, but the 
interpretation of the information in the message may require additional knowledge. The standard does not preclude 
the specification of any reference frame using either Q_FRAME_A or Q_FRAME_B. For instance, a particular 
APM could specify a transformation from ITRF-2000 to J2000, or a transformation from SC_BODY to DSS_x. 
The final keyword necessary to fully specify the quaternion is the direction of the rotation. The keyword Q_DIR is 
provided and can have the values A2B or B2A. The keyword value A2B, given specifications of the reference 
frame given by Q FRAME A and the body frame given by Q FRAME B, will transform from Q FRAME A to 
Q_FRAME_B, and vice versa if Q_DIR has the value B2A. An example APM using quaternions is shown in Figure 
3. 

Figure 3: APM Example using Quaternions 


CCSDS_APM_VERS 

= 

1.0 

CREATION_DATE 

= 

2010-09-30T19:23:57 

ORIGINATOR 

= 

GSFC 

OB JE C T_N AME 

= 

MYSAT 

OB JECT_ID 

= 

2008-00 9A 

CENTER_NAME 

= 

EARTH 

TIME_SYSTEM 

= 

UTC 

EPOCH 

= 

2010-09-30T14:28:15.1172 

Q_FRAME_A 

= 

SC BODY 

Q_FRAME_B 

= 

ITRF-97 

Q_DIR 

= 

A2B 

Ql 

= 

0.00005 

Q2 

= 

0 . 87543 

Q3 

= 

0 . 40949 

Q4 

= 

0.25678 


Euler angles are another parameterization of attitude that utilize angular values to express the attitude 
transformation, and a rotation sequence to apply the angles. The metadata necessary to interpret Euler angle data are 
shown in Table 2. 


Table 2: Relevant Euler Angle Metadata 


Keyword 

Description 

Value Examples 

EULERFRAMEA 

Body-fixed, inertial or rotating reference frame 

SCBODY 

STARTRACKER 











EULERFRAMEB 

Body-fixed, inertial or rotating reference frame 

ICRF 

ITRF-97 

EULERROTSEQ 

keyword for the sequence of rotation axes 

123 

321 

EULERDIR 

direction of the Euler angle rotation, whether from 

A2B 


EULER B FRAME to EULER FRAME, or vice versa 

B2A 

RATEFRAME 

If desired to specify Euler angle rates, this keyword is used 

EULERFRAMEA 


to specify the reference frame used to express the Euler 
angle rates 

EULERFRAMEB 


The final pieces of information necessary for the specification of Euler angles are the Euler angles themselves. The 
keywords provided for the specification of the Euler angles are X_ANGLE, Y_ANGLE and Z_ANGLE, denoting an 
X, Y and Z body axis rotation angle, respectively. The corresponding Euler angle rates are specified using the 
keywords XRATE, YRATE, and Z RATE denoting an X, Y and Z body rotation rate. Note that typically an 
attitude is specified using a quaternion and the Euler angle rates of the body with respect to an inertial frame, given 
in the body fixed frame. This parameterization of the attitude could be specified as in the example in Figure 4. 


Figure 4: Example of Quaternions and Euler rates to Specify an Attitude Transformation 


CCSDS_APM_VERS 

CREATION_DATE 

ORIGINATOR 

OBJECT_NAME 

OBJECT_ID 

CENTER_NAME 

TIME SYSTEM 


= 1.0 

= 2012-01-21T19:23:57 
= GSFC 
= YOURSAT 
= 2009-024B 
= MARS 
= UTC 


EPOCH 

Q_FRAME_A 

Q_FRAME_B 

Q_DIR 

Q1 

Q2 

Q3 

QC 

COMMENT Euler rates 


= 2012-01-21T19:21:49.3455 
= SC_BODY 
= J2000 
= A2B 
= 0.03123 
= 0.78543 
= 0.39158 
= 0.47832 

of YOURSAT w.r.t. Mars J2000, 


given in the body 


COMMENT frame 


EULER_FRAME_A 

EULER_FRAME_B 

EULER_ROT_SEQ 

RATE_FRAME 

ROLL_RATE 

PITCH_RATE 

YAW RATE 


= SC_BODY 
= J2000 
= 312 

= EULER_FRAME_A 
= 0.1045 [deg/s] 

= 0.03214 [deg/s] 

= 0.02156 [deg/s] 


The final specification of attitude in an APM is that of a spinning spacecraft using the specification of right 
ascension and declination of the spin axis, the phase of the spin and the angular velocity of the spinning vehicle to 
fully specify the spin attitude. In addition to this information, the spin attitude can be augmented by providing 
information about the nutation of the spin by specifying the nutation angle, nutation period and the nutation phase. 
This information will fully specify the orientation of the spin axis and enable the user to propagate the spin attitude. 
In addition to the spin parameterization, the message must specify reference frame information similar to those 
specified in the quaternion and Euler angle sections. The keywords provided for the specification of attitude for a 
spinning satellite are summarized in Table 3. 
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Table 3: Keywords for the Attitude of a Spinning Satellite 


Keyword 

Description 

Example Values or Units 

SPINFRAMEA 

Body-fixed, inertial or rotating reference frame 

SCBODY 

TAM_1 

SPINFRAMEB 

Body-fixed, inertial or rotating reference frame 

ITRF-97 

J2000 

SPINDIR 

Direction of spin rotation 

B2SPIN 

SPIN2B 

SPINALPHA 

Right ascension of the spin axis vector 

deg 

SPINDELTA 

Declination of the spin axis vector 

deg 

SPINANGLE 

Phase of the satellite about the spin vector 

deg 

SPINANGLEVEL 

Angular velocity of the satellite around spin axis 

deg/s 

NUTATION 

Nutation angle of spin axis 

deg 

NUTATIONPER 

Body nutation period of the spin axis 

seconds 

NUTATIONPHASE 

Inertial nutation phase 

deg 


In addition to the specification of attitude using a quaternion, Euler angles, or spin parameters, an APM also allows 
for the specification of attitude maneuvers. The maneuvers are specified irrespective of the torque that generated the 
maneuver, but rather specify the torque itself. The keywords provided for a maneuver are the start time of the 
maneuver (MANEPOCHSTART), the duration of the maneuver (MAN DURATION), the reference frame for 
the maneuver (MAN_REF_FRAME), and finally the torques to apply for the maneuver, MAN_TOR_l, 
MAN_TOR_2, MAN_TOR_3. To properly interpret this information, other keywords are provided to specify the 
inertias of the object, but these do not necessarily need to be repeated for each maneuver. 

Attitude Ephemeris Message (AEM) 

The attitude ephemeris message takes much of this same information and attempts to compact it for delivering the 
attitude at multiple epochs in a single message. This compacting is achieved by specifying more information in the 
metadata that enables the unambiguous interpretation of the attitude data that follow. In addition to the standard 
header, the metadata for an AEM consists of the name of the object and its identification number (OBJECT_NAME 
and OBJECTID), the time system used to specify the epochs (TIME_SYSTEM), the reference frames, 
REF FRAME A and REFFRAMEB, a keyword for the direction of the rotation (ATTITUDE DIR), and the start 
and stop times of the attitude data (START TIME, STOP TIME). 

In addition to these necessary parameters, the AEM achieves compactness by having an ATTITUDE_TYPE 
keyword that denotes the format of the lines of data that are in a message. There is no mandatory set of data that 
must be provided in an AEM, so the provider is free to specify attitude using any of several pre-defined 
parameterizations. The values for the ATTITUDE_TYPE keyword are summarized in Table 4. 


Table 4: Values and Description for ATTITUDE_TYPE in an AEM 


j Keyword 

Value 

AEM Data Line | 

| Quaternion Options | 

QUATERNIONTYPE 

FIRST 


ATTITUDETYPE 

QUATERNION 

Epoch, QC,Q1,Q2, Q3 

QUATERNION/DERIVATIVE 

Epoch, QC, Ql, Q2, Q3, 

QC DOT, Q1DOT, Q2 DOT, Q3 DOT 
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QUATERNION/RATE 

Epoch, QC, Ql, Q2, Q3, 
XRATE, YRATE, ZRATE 

| Euler Angle Options | 

ATTITUDETYPE 

EULERANGLE 

Epoch, XANGLE, YANGLE, ZANGLE 

EULERANGLE/RATE 

Epoch, X ANGLE, Y ANGLE, Z ANGLE, 
X RATE, Y RATE, Z RATE 

| Spin Axis Options | 

ATTITUDETYPE 

SPIN 

Epoch, SPINALPHA, SPINDELTA, 
SPINANGLE, SPIN ANGLE VEL 

SPIN/NUTATION 

Epoch, SPIN ALPHA, SPIN DELTA, 
SPIN ANGLE, SPING ANGLE VEL, 
NUTATION, NUTATIONPER, 
NUTATIONPHASE 


In the case of the ‘Quaternion Options’, there is a keyword QUATERNIONTYPE that allows the user to have the 
scalar value of the quaternion specified as the first or last element. The lines for the keyword 
QUATERNION TYPE = LAST are not shown in Table 4. In addition, other keywords are provided to fully specify 
the interpretation of the attitude. There are also keywords to complete the specification of Euler angles and Euler 
rates using EULER ROT SEQ to specify the rotation sequence, and RATE_FRAME to specify the Euler rates 
frame. Figure 5 gives an example of an AEM using quaternions and Euler rates. 


Figure 5: AEM example using Quaternions and Euler rates 


CCSDS_AEM_VERS 
CRE AT I ON_DATE 
ORIGINATOR 
META_START 
OB JE C T_N AME 
OB JECT_ID 
RE F_FRAME_A 
RE F_FRAME_B 
ATTITUDE_DIR 
TIME_SYSTEM 
START_TIME 
STOP_TIME 
ATTITUDE_TYPE 
QUATERNION_TYPE 
META_STOP 
DAT A_S TART 

2012-11-04T09: 14 : 34 .5633 


= 1.0 

= 2012-11-04T17 :22 : 31 
= NASA/ JPL 

= bigsat 
= 2010-001A 
= EME2000 
= SC_BODY 
= A2B 
= UTC 

= 2012-11-04T09:14:34.5633 
= 2012-11-04T09:44:19.4533 
= QUATERNION/RATE 
= FIRST 


0.56748 0.03146 0.45689 0.68427 0.024 0.001 0.003 


2012-11-04T09:44:19.4533 -0.84532 0.26974 -0.06532 0.45652 0.001 0.001 0.020 
DATA STOP 


Recently, the ADM has gone through the CCSDS Agency Review, and prototypes are in development at CNES and 
NASA/GSFC. Upon completion of the implementation testing phase of the CCSDS Standardization Process, the 
Navigation Working Group plans to progress the ADM to a CCSDS Blue Book subsequent to the CCSDS Fall 2007 
Meetings at Heppenheim, Germany, with the approval of the CESG. 
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Tracking Data Message 

The Tracking Data Message (TDM) specifies a standard message format for use in exchanging spacecraft tracking 
data between tracking data users, primarily the world’s space agencies. Such exchanges are used for distributing 
hacking data output from routine interagency cross-supports in which spacecraft missions managed by one agency 
are tracked from a tracking station managed by a second agency. The standardization of tracking data formats 
facilitates space agency allocation of tracking sessions to alternate tracking resources and international cooperation 
in the provision of tracking services. 

The TDM standard is designed for the inter-agency exchange of tracking data types such as Doppler, 
transmitted/received frequencies, range, angles, Delta-DOR (Differenced One-Way Ranging), media correction, 
weather, etc. Part of the challenge associated with this range of data types has been arriving at a keyword set that is 
broad enough to meet all needs, but still retains the notion of economy and general applicability. Table 5 below lists 
the TDM Data Section keyword set that has been agreed upon. 


Table 5: Summary Table of TDM Data Section Keywords 


Keyword 

Units 

Notes 

Signal Related Keywords 



CARRIER POWER 

dBW 

Strength of radio signal, as received at 
ground 

DOPPLER INSTANTANEOUS 

km/s 

Instantaneous range rate of spacecraft 

DOPPLER INTEGRATED 

km/s 

Mean range rate of the spacecraft over the 
INTEGRATIONINTERVAL 

TJ 

O 

1 

o 

dBHz 

Carrier power to noise spectral density ratio 

PR NO 

dBHz 

Ranging power to noise spectral density ratio 

RANGE 

km , RU or s 

Range measurements from ambiguous 
ranging systems, differenced range, skin 
radar, proximity radar, or similar radar 

RECEIVE FREQ 

Hz 

Measurements of the received frequency 

TRANSMIT FREQ n (n = 1, 2, 3, 

4, 5) 

Hz 

Measurements of a transmitted frequency 

TRANSMIT FREQ RATE n (n = 1, 2, 

3, 4, 5) 

Hz/s 

Linear rate of change of the transmit 
frequency starting at the timetag 

VLBI/Delta-DOR Related Keywords 



DOR 

s 

Used for the spacecraft observable in a Delta- 
DOR measurement. 

VLB I DELAY 

s 

Used for the quasar observable in a Delta- 
DOR measurement. 

Angle Related Keywords 



ANGLE 1 

deg 

Azimuth, right ascension, or ‘X’ angle of the 
measurement, depending on the value of the 
ANGLE_TYPE keyword 

ANGLE 2 

deg 

Elevation, declination, or ‘Y’ angle of the 
measurement, depending on the value of the 
ANGLE TYPE keyword. 

Time Related Keywords 
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Keyword 

Units 

Notes 

CLOCK BIAS 

S 

Used to reflect clock offsets between 2 clocks 
(e.g., station clock and UTC). 

CLOCK DRIFT 

s/s 

Used to reflect clock drifts between 2 clocks 
(e.g., station clock and UTC). 

Media Related Keywords 



STEC 

TECU 

Slant Total Electron Count 

TROPO DRY 

m 

Dry zenith delay through the troposphere 

TROPO WET 

m 

Wet zenith delay through the troposphere 

Meteorological Related Keywords 



PRESSURE 

hPa 

Barometric pressure 

RHUMIDITY 

% 

Relative humidity 

TEMPERATURE 

K 

Temperature at the timetag 


As noted earlier, each of the NDMs has a metadata section. For the TDM, the metadata section contains a large 
number of keywords that qualify the data section keywords and provide supplementary information that is necessary 
in order to interpret the data. There are a few metadata keywords that are required for every TDM, but in general 
there are only a very small number because most of the metadata keywords would be meaningless for several data 
types. For example, for the integrated Doppler data type, it is necessary to know the INTEGRATION_INTERVAL 
and the INTEGRATION_REF. The first of these is self-explanatory; the second provides the information as to 
whether the timetag on the data is the start, middle or end of the integration period. For some special applications, it 
is also necessary to know the TIMETAG_REF, i.e., is the timetag the transmit time or the receive time. In many 
cases this is somewhat obvious, but there are some applications in which data normally considered downlink data is 
tagged with the transmit time. But these three metadata keywords are not necessary to explain media calibration 
data or clock data. Other metadata keywords in the TDM include the START TIME, STOP TIME, the tracking 
MODE associated with the data, the signal PATH, TRANSMIT BAND, RECEIVE BAND, FREQ OFFSET, 
RANGEMODE, RANGEMODULUS, RANGEUNITS, ANGLETYPE, REFERENCEFRAME, 
TRANSMITDELAY, RECEIVE DELAY, DATA QUALITY, and a set of CORRECTION * keywords which 
apply to the various data types. One of the most important metadata keywords, required in all TDMs, is the set of 
PARTICIPANT_n keywords. These are used to identify the entities involved in the tracking session (spacecraft, 
antennas, quasars, etc.). For any given TDM data type, the metadata keywords fall into three categories: required 
metadata, situation-specific required metadata, and completely optional metadata. 

Because of the large amount of data typically collected in a tracking pass, the TDM is suited to inter-agency 
exchanges from one computer to another (e.g., file transfer). It is acknowledged that the first version of the TDM 
may not apply to every single tracking session or data type; over the years engineers have developed many very 
creative ways to track their spacecraft. However, it is desired to focus on covering approximately the ‘95% level’ of 
hacking scenarios, and to expand the coverage in future versions as experience with the TDM is gained. 

Based on the variety of data types, and the variety of hacking systems which exist in the various agencies, it is 
recommended that the TDM be supplemented by an ICD written jointly by the service provider and customer 
agency that discusses such things as hacking instrument locations, corrections that will or will not be applied to the 
data, the specific methods of transferring data that will be supported, frequency of exchange, etc. 
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The TDM standard is applicable only to the message format and content, but not to its transmission. The method of 
transmitting of the message between exchange partners is beyond the scope of the standard, but message 
transmission could be based on a CCSDS data transfer protocol, file based transfer protocol such as SFTP, stream- 
oriented media, or other secure transmission mechanism. In general, the transmission mechanism must not place 
constraints on the technical data content of a TDM. While many of the agencies which plan to use the TDM are 
considering transferring file-based TDMs, another CCSDS Working Group, the Cross Support Transfer Services 
Working Group, is in the process of developing a standard for the real time transfer of radiometric tracking data that 
will use the TDM as the data format. 


Completion of the TDM has been identified by the Interagency Operations Advisory Group (IOAG, 
http://www.ioag.org) as one of its top priorities. The IOAG is a consortium of the world’s major space agencies that 
provides suggestions for interoperability standards and requirements to standards organizations (CCSDS, Space 
Frequency Coordination Group) and requirements organizations (Interagency Coordination Panel, Interagency 
Programs and Projects). 

Recently, the TDM has gone through two CCSDS Agency Reviews, and prototypes are in development at DLR, 
ESA and NASA/JPL. Upon completion of the implementation testing phase of the CCSDS Standardization Process, 
the Navigation Working Group plans to progress the TDM to a CCSDS Blue Book subsequent to the CCSDS Fall 
2007 Meetings at Fleppenheim, Germany, with the approval of the CESG. The first operational use of the Tracking 
Data Message may come in late 2007 with the exchange of Delta-DOR data collected by ESA ground stations 
hacking NASA’s Phoenix spacecraft. 


Figures 6 and 7 are example TDMs drawn from the standard document. The first conveys transmitted frequencies, 
transmitted frequency rates, and received frequencies that can be used in a Doppler calculation. The second conveys 
integrated Doppler, range, and angle data in a single TDM. These represent only 2 examples of the kinds of hacking 
data that may be exchanged via the TDM. It is a very flexible data structure, which makes it prohibitive to show 
examples of all the ways in which a TDM can be formed within the confines of this paper. Interested readers are 
referred to Annex D of the TDM document [3], which contains a much larger set of examples of TDMs, 
encompassing the full range of data types which may be exchanged via the TDM. 

Figure 6: TDM Example of Two-Way Frequency Data for Doppler Calculation 

CCSDS_TDM_VERS=1 . 0 

COMMENT TDM example created by yyyyy-nnnA Nav Team (NASA/JPL) 

CREATION_DATE=2005-184T20 : 15 : 00 

ORIGINATOR=NASA/JPL 

META_START 

TIME_SYSTEM=UTC 

START_T IME=2 005-184T11 : 12 : 23 

STOP_TIME=2005-184T13 : 59:48.27 

PARTICIPANT_l=DSS-55 

PARTICIPANT_2=yyyy-nnnA 

MODE=SEQUENTIAL 

PATH=1, 2, 1 

TIMETAG_REF=RECEIVE 

INTEGRATION_INTERVAL=l . 0 

INTEGRATION_REF=MIDDLE 

FREQ_OFFSET=0 . 0 

META_STOP 

DAT A_S TART 

TRANSMI T_FREQ_1=2 005-184T11 :12:23 7175173383.615373 

TRANSMIT_FREQ_RATE_1=2005-184T11 : 12 : 23 0 . 40220 
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7175173384 . 017573 


TRANSMI T_FREQ_1=2 005-184T11 : 12 : 24 
TRANSMI T__FREQ_RATE_1 =2 005-184T11 : 12 : 24 0 . 40220 

TRANSMI T_FREQ_RATE_1 =2 005-184T11 : 12 : 36 0 . 40220 

TRANSMI T__FREQ_1 =2 005-184T11 :12:37 7175173389.246173 

TRANSMI T_FREQ_RATE_1 =2 005-184T11 : 12 : 37 0 . 40220 

TRANSMI T_FREQ_1 =2 005-184T11 :12:38 7175173389.648373 

RECEIVE_FREQ_1=2005-184T13 : 59 : 27 . 27 8429753135.986102 

RECEIVE_FREQ_1=2005-184T13: 59:28 .27 8429749428.196568 

RECEIVE_FREQ_1=2005-184T13: 59: 41 .27 8429749420.204178 

RECEIVE_FREQ_1=2005-184T13: 59: 42 .27 8429749419.596043 

DATA_STOP 

Figure 7: TDM Example of Angles, Range and Doppler Combined in a Single TDM 

CCSDS_TDM_VERS =1.0 
COMMENT GEOSCX 

CREATION_DATE = 2 0 0 6-12 -0 8T1 0 : 12 : 4 0 . 4 72 
ORIGINATOR = GSOC 

META_START 
TIME_SYSTEM = UTC 

START_TIME = 2005-12-15T00 : 00 : 02 . 000 

STOP_TIME = 2005-12-18T23 : 59 : 42 . 000 

PARTICIPANT^ = WHM1 

PARTICI PANT_2 = EW5 

MODE = SEQUENTIAL 

PATH = 1,2,1 

INTEGRATION_INTERVAL = 10.0 

INTEGRATION_REF = END 
RANGE_MODULUS = 1.000000E+07 

ANGLE_TYPE = AZEL 
DATA_QUALITY = RAW 
META_STOP 

DAT A_S TART 
ANGLE_1 
ANGLE_2 
RANGE 

DO PPLER_INTE GRATED 
ANGLE_1 
ANGLE_2 
RANGE 

DO PPLER_INTE GRATED 

ANGLE_1 
ANGLE_2 
RANGE 

DO PPLER_INTE GRATED 
ANGLE_1 
ANGLE_2 
RANGE 

DO PPLER_INTE GRATED 
DATA STOP 


= 2005-12-15T00 : 00 : 02 . 000 57.691180 

= 2005-12-15T00 : 00 : 02 . 000 37.052172 

= 2005-12-15T00 : 00 : 02 . 000 3 . 824634898E+04 

= 2005-12-15T00 : 00 : 02 . 000 -1.781311000 

= 2005-12-15T00 : 00 : 12 . 000 57.680980 

= 2005-12-15T00 : 00 : 12 . 000 37.064578 

= 2005-12-15T00 : 00 : 12 . 000 3 . 824629493E+04 

= 2005-12-15T00 : 00 : 12 . 000 -1.761957000 

= 2005-12-18T23:59:32.000 219.206514 

= 2005-12-18 T2 3:59:32. 000 27.411017 

= 2005-12-18 T2 3:59:32. 000 3 . 908802298E+04 

= 2005-12-18T23:59:32.000 -2.175859000 

= 2005-12-18 T2 3:59:42. 000 219.226135 

= 2005-12-18T23:59:42.000 27.367472 

= 2005-12-18 T2 3:59:42. 000 3 . 908801697E+04 

= 2005-12-18 T2 3:59:42. 000 -2.153102000 
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Conclusion 


It is essential to develop standards to serve the purpose of easing communications and correct interpretation of data 
for future space missions within an agency and between agencies. In particular, interagency partnering in the 
operation of space missions is becoming more and more widespread; the development and use of international 
standards is essential to accommodating such partnering in an efficient fashion. The Navigation Data Messages 
detailed here have encapsulated the necessary information for processing of orbit, attitude and tracking data into a 
compact message that can be read by humans and computers. It is hopeful that the implementation of these 
standards into future systems is not overly burdensome, but moreover they are of a benefit to the agencies that use 
them and exchange them. The Navigation Data Messages presented here give a specification and unambiguous 
interpretation of orbit, attitude and tracking data as can be shown in the examples here, and those in [1], [2], and [3], 

Acknowledgements 

The authors would like to acknowledge the leaders in CCSDS for allowing us the time to get this right, most notably 
the Area Director of MOIMS, Nestor Peccia (ESA). Finally, we would like to acknowledge the efforts of Felipe 
Flores-Amaya, recently retired Chairman of the Navigation Working Group for shepherding the bulk of the progress 
on these standards over the past several years. 


References 

1. Orbit Data Messages, Recommendation for Space Data System Standards, CCSDS 502.0-B-l, Blue Book, 
Issue 1, Washington, D.C., CCSDS, September 2004. 

2. Attitude Data Messages, Draft Recommendation for Space Data System Standards, CCSDS 504.0-R-l, Red 
Book, Issue 1, Washington, D.C., CCSDS, November 2005. (Available in updated working draft Issue 1.6 
from Navigation WG). 

3. Tracking Data Message, Draft Recommendation for Space Data System Standards, CCSDS 503.0-R-2, Red 
Book, Issue 2, Washington, D.C., CCSDS, December 2006. (Available in updated working draft Issue 2.5 
from Navigation WG). 

4. Navigation Data — Definitions and Conventions. Report Concerning Space Data System Standards, CCSDS 
500.0-G-2. Green Book. Issue 2. Washington, D.C.: CCSDS, November 2005. 

5. XML Specification for Navigation Data Messages. Draft Recommendation for Space Data System Standards, 
CCSDS 505.0-R-l, Red Book, Issue 1, Washington, DC, CCSDS, November 2005. (Available in updated 
working draft Issue 1 .2 from Navigation WG) 

6. Information Technology - 8-Bit Single-Byte Coded Graphic Character Sets — Part 1 : Latin Alphabet No. 1. 
International Standard, ISO/IEC 8859-1:1998. Geneva: ISO, 1998. 

7. IEEE Standard for Binary Floating-Point Arithmetic. IEEE Standard 754-1985, New York, IEEE, 1985. 

8. Wertz, James R. (editor), Spacecraft Attitude Determination and Control, Kluwer Academic Publishers, 
Boston, 1978. 

9. Martin-Mur, Tomas, et. al., “ Exchange of Standardized Flight Dynamics Data”, Proceedings of the 18 th ISSFD, 
Munich, Germany, 2004. 

10. Restructured Organization and Processes for the Consultative Committee for Space Data Systems, CCSDS 
A02.1-Y-2, Yellow Book, Issue 2, Washington, D.C., CCSDS, April 2004. 

11. Time Code Formats, Recommendation for Space Data System Standards, CCSDS 301.0-B-3, Blue Book, Issue 
3, Washington, D.C., CCSDS, January 2002. 

12. International System of Units (SI), National Institute of Standards and Technology, 
http://physics.nist.gov/cuu/Units , October 2000. 


16 


